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ABSTRACT 


This  thesis  ex2unines  the  planned  implementation  of  the  DMS 
and  its  impact  on  the  Department  of  Defense  (DoD) ,  the  Navy 
and,  specifically,  naval  surface  ships.  The  DMS  "phased" 
planning  will  be  evaluated,  with  a  concentration  on  several 
key  technological  developments  that  will  support  the 


modernization  of  the  DoD  messaging  system. 
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I.  IirrRODDCTIOH 


The  Defense  Message  System  (DMS)  is  a  bold  attempt  to 
bring  the  Department  of  Defense  (DoD)  and  its  communications 
and  message  distribution  systems  into  the  twenty-first 
century.  This  commxinications  evolution  will  rely  heavily  on 
technologies  beinc  developed  in  industry  which  promise  to 
revolutionize  both  the  computer  and  telecommtmications  fields 
(i.e..  Integrated  Services  Digital  Network  (ISDN)  ^  fiber  optic 
communications,  Open  Systems  Interconnection  (OSI) ,  etc.). 

The  DMS  is  merely  an  aggressive  "phased**  plan  of  action 
which  will  overhaul  and  combine  aging  DoD  communications 
systems  that  have  suffered  in  the  past  from  labor-intensive 
procedures,  antiguated  equipment  and  the  inability  to  meet 
the  tremendous  demands  that  are  being  placed  on  them.  This 
much  needed  renovation  will  be  achieved  by  the  complete 
redesigning  of  a  worldwide  telecommunications  network  to 
replace  the  DoD's  aging  Automated  Digital  Network  (AUTpDIN) . 

The  AUTODIN  is  often  overtaxed  afi  it  is  limited  in  its 
capacity  to  expand  due  to  its  reliance  on  outdated,  inflexible 
technologies.  CMS  will  be  based  on  highly  efficient  and 
inexpensive  computerized  communications  networks  that  provide 
sufficient  capacities  to  meet  future  DoD  messaging  demands. 


A.  SCOPE 


This  thesis  will  examine,  from  the  messaging  system  user's 
perspective,  the  basis  of  the  DMS  program  as  it  pertains  to 
the  DoD  in  general  and  the  Navy  specifically.  A  closely 
integrated  DMS  development  program  requires  the  evolvement  of 
all  rhe  components  of  the  OoD,  from  the  highest  levels  in  the 
Pentagon  down  to  the  "radio  shack"  on  Navy  surface  ships ,  to 
circumvent  the  potential  "pitfalls"  of  technological 
renovation  on  this  Scale. 

As  DoD-wide  telecommunication  innovations  are  set  in 
motion,  it  is  anticipated  chat  there  will  be  tremendous  cost 
savings  as  a  result  of  reductions  in  the  manual  processing 
that  has  plagued  the  current  messaging  system.  Along  with  the 
promise  of  cost  savings  is  the  unfortunate  potential  for  cost 
growth.  This  cost  additive  condition  might  occur  as  a  result 
of  needs  to  provide  duplicate  communication  systems,  as  the 
technological  advances  of  the  "new-age"  in  digital 
communications  find  themselves  heavily  dependent  on  other, 
simultaneously! developing  technologies  (i.e.,  ISDN, 
X.400/X.500,  etc.).  These  "other  technologies"  will  be 
defined  in  terms  of  their  role  in  the  DMS  development  and 
their  potential  to  either  revolutionize  DoD  telecommunications 
or  hopelessly  entangle  it  due  to  program  delays. 

B.  THESIS  OUTLINE 

To  lay  the  foundation  for  the  total  revamping  of  the  DoD 
messaging  system,  the  DMS  entablishes  a  starting  point  as  it 
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maps  its  way  toward  an  intended  target  architecture  by  the 
year  2008.  Chapter  II  outline  the  justifications  and 
objectives  of  the  DMS  program  as  it  passes  through  each  phase 
of  its  metamorphosis. 

Chapter  III  examines  a  vital  link  to  the  DMS  evolution, 
that  establishes  the  groundwork  for  a  user-lev‘%1  connection  to 
the  worldwide  messaging  network.  This  vital  link,  as  it 
pertains  specifically  to  the  Navy,  is  the  ^ase  Information 
Transfer  System  (BITS) .  BITS  is  a  Navy  specific,  base 
communication  modernization  plan,  that  will  prcwida  the  vital 
shore^based  interface  to  the  DMS  network. 

As  DMS  planners  approach  the  waterfront,  the  system  design 
becomes  complicated  by  the  fact  that  most  Navy  ships  go  to  sea 
periodically  and,  therefore,  require  special  consideration. 
The  established  ship-based  ship-to-shore  message  system 
currently  requires  two  systems,  one  for  in  port  periods  and 
another  while  at  sea.  Recent  developments  in  shipboard 
telecommunications  will  be  presented  in  Chapter  IV  in  an 
attempt  to  close  the  gap  between  shore-based  messaging  arid  the 
special  requirements  for  at-sea  u8ers. 

Chapter  V  presents  a  novel  twist  to  the  DMS  evolutionary 
process  as  it  concludes  the  thesis  by  examining  the 
reunifications  of  a  rapidly  shrinking  gap  between 
communications  and  computers  in  the  DoD  while  reshaping 
shipboard  messaging  as  "The  Impact  of  the  Defense  Message 
System  on  the  United  States  Surface  Navy"  becomes  significant. 


II.  AN  OVERVIEW  OF  THE  DEFENSE  MESSAGE  SYSTEM 

The  Defense  Message  System  (DMS)  is  a  Department  of 
Defense  (DoD)  evolutionary  implementation  plan  that  is 
intended  to  provide  an  integrated  massaging  system  baaed  on 
the  concept  of  standardization  and  interoperability,  while 
remaining  flexible  enough  to  be  responsive  to  individual 
organizational  needs  [Ref.l:p  1-4].  The  starting  point  of  the 
DMS  will  be  the  DoD  messaging  system  as  it  existed  in 
September  1939,  and  will  pass  through  three  major  phases 
before  it  arrives  at  its  expected  targat  architecture  in  the 
year  2008.  This  final  architecture  will  establish  a  direct 
link  between  the  writer  of  the  message  and  its  intended  reader 
in  an  attempt  to  speed-up  the  message  communication  process 
while  reducing  costs  by  taking  advantage  of  modem  computer 
and  communications  systems. 

A.  CONDITIONS  FOR  CHANGE 

The  problems  and  costs  of  the  current  messagirig  system 
were  compounded  by  the  lack  of  standardization  and  the  heavy 
reliance  on  manpower-intensive  procedures.  This  slow  and 
expensive  system  suffered  from  the  eUasence  of  a  DoC-wide 
communications  architecture,  as  each  individual  service 
stzruggled  to  meet  operational  requirements  with  a  mixed  bag  of 
antiquated  networks,  computers,  protocols  and  procedures. 
Adding  to  the  argximent  for  modernisation  was  the  fact  that  as 
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the  computing  speed  and  availadjle  transmission  bandwidth 
increased  in  the  marketplace,  the  costs  associated  vV.h  these 
advancements  were  decreasing  rapidly. 

In  January  1988,  as  budgetary  constraints  became  ever  more 
prevalent  and  the  existing  messaging  systems  began  to  reach 
their  operating  limits,  the  Assistant  Secretary  of  Defense  for 
Command,  Control,  Communications  and  Intelligence  (ASD/C^I) 
brought  together  a  working  group  to  establish  a  strategy  for 
the  development  of  a  OoO-wide  system.  This  working  group  was 
a  joint  DoD  effort,  and  by  February  1989  they  had  developed 
and  validated  a  comprehensive  planning  document  knovm  as  the 
Multi-command  Required  Operational  Capability  for  the  Defense 
Message  System  (DMS  HROC  3-88).  [Ref.l:p.  1-1] 

To  date,  the  DMS  has  been  driven  by  MROC  3-88  tasking,  and 
DoD  working  groups  have  since  produced  several  iterations  of 
very  extensive  planning  documents.  The  remainder  of  this 
chapter  will  be  dedicated  to  the  examination  of  the  planned 
phases  of  the  DMS,  development  criteria  and  key  evolutionary 
considerations. 

B.  THB  SCOPE  OF  DMS 

The  focus  of  the  DMS  will  concentrate  on  all  hardware, 
software,  procedures,  standards,  facilities  and  personnel  that 
are  currently  involved  in  any  aspect  of  the  existing  DoD 
strategic  messaging  system,  to  include  both  tactical  and 


allied  interfaces  [Ref.  l:pp.  1-1  1-2].  The  primary  DMS 

development  efforts  will  concentrate  on  a  rather  extensive  set 
of  objectives  that  have  been  mandated  by  MROC  3-88  [Ref.  1: 
pp.  1-5  -  1-8]; 

*  Connectivity/Interoperability 

*  Guaranteed  Delivery/Accountability 

*  Timely  Delivery 

*  Confidentiality/Security 

*  Sender  Authentication 

*  Integrity 

*  Survivability 

*  Avail2dbility/Reliability 

*  Ease  of  Use 

*  Message  Preparation  Support 

Each  OHS  objective  has  been  mea  jred  against  the  service 
quality  of  the  existing  system  (Baseline  system)  to  ensure 
that  there  is  true  progress  during  the  evolutionary  process, 
with  the  underlying  goal  being  to  reduce  cost  and  staffing 
requirements  [Ref.  l:p.  1-7]. 

The  DMS  will  gather  under  one  umbrella  all  forms  of 
narrative  messaging  systems  currently  employed  in  the  DoD. 
The  term  "narrative  message"  is  defined  in  allied 
communication  publications  as  "any  thought  or  idea  expressed 
briefly  in  plain  or  secret  language,  prepared  in  a  form 
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suitable  for  transmission  b^-  emy  means  for  commimications. " 
Within  the  scope  of  the  DMS,  of  "means  of  communications"  will 
be  limited  to  electronic  methods.  Under  "electronic  means", 
there  are  currently  two  primary  classes  of  message  in  use  and 
those  are : 

*  Organizational  -  These  are  commonly  known  as 
"Commanding  Officer-to-Commanding  Officer"  messages. 
Because  of  their  official  nature,  these  messages 
Impose  critical  operational  requirements  on  the 
communicaticn  system  [Ref.  l:p.  1-3]. 

*  Individual  -  This  class  of  message  has  found  an 
electronic  foothold  with  the  advent  of  computer 
networks.  It  is  often  in  the  form  of  "working" 
communications  between  DoD  personnel  and  of  an 
administrative  nature  [Ref.  2:pp.  10  -  12]. 

The  mission  of  the  DMS  will  be  to  handle  every  message 

with  an  appropriate  level  of  service  quality  with  respect  to 

its  classification,  content  and  precedence.  Currently, 

electronic  messages  are  being  handled  by  the  following 

components : 

1.  AUTODIM 

AUTODIN  is  the  primary  of  the  current  messaging 
system,  and  will  Increasingly  be  requited  to  interface  vith 
Local  Area  Networks,  (LANs)  and  Office  Automation  Syst ems 
(OASs)  as  DMS  evolves.  It  is  for  this  reason  that  DoD  has 
selected  the  X.400  Message  Handling  System  protocol  (MHS)  as 
the  DMT  standard.  Like  the  current  AUTODIN  system,  X.400  uses 
the  stpre-and-forward  message  transfer  system.  The  AUTCOIN 
system  is  of  1960s  vintage  and  is  comprised  of  many  outdated, 


7 


labor-intensive  elements,  which  are  the  prime  target  of  the 
DMS  automation. 

The  following  is  a  listing  of  the  major  components  of 
AUTODIN  [Ref.  2;pp.  12-14]: 

*  AUTODIN  Switching  Centers  (ASCs; .  The  15  ASCs  are 
distributed  around  the  world  and  provide  the  primary 
store-and- forward  message  switching,  message 
validation,  format  conversion  and  routing  functions 
[Ref.  l:p.  2-1]. 

*  Automated  Message  Processing  Exchanges  (AMPEs) .  There 
are  over  100  AMPEs  and  despite  the  fact  that  they  all 
perform  roughly  the  same  mission  they  have  different 
equipment,  procedures  and  names  (i.e..  Army's 
Automated  Multi-media  Exchange  (AMME) ,  Navy's  Local 
Digital  Message  Exchange  (LDMX)  and  the  Air  Force's 
Air  Force  Automated  Message  Processing  Exchange 
(AFAMPE))  [Ref.  3:p.  59]. 

*  Telecommunications  Centers  (TCCs) .  There  are  over 
1000  TCCs  and  they  are  the  primary  input  and  output 
points  of  the  current  AUTODIN  messaging  system.  It  is 
these  TCCs  that  are  targeted  by  DMS  planners  for 
limited  messaging  system  automation,  but  eventually 
they  will  be  phased  out. 

2.  E-Mail 

Currently,  the  Defense  Data  Network  (DDN)  is  providing 
the  backbone  for  the  transportation  of  the  bulk  of  the  data 
being  transmitted  in  the  DoD  [Ref.  4].  In  the  near  future, 
the  DDN  will  be  acting  as  the  primary  transportation  medium 
for  the  DMS  as  the  message  traffic  currently  transmitted  via 
the  AUTODIN  network  will  be  migrated  to  the  DDN  backbone  [Ref. 
5:p.  76]. 
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The  existing  DON  backbone  system  includes  [Ref.  2:p. 

13]: 

*  Host  computers  that  support  E-Mail 

*  On-line  directories 

*  User  terminal  access  for  Personal  Computers  (PC) 

*  DoD  Classified  Internet: 

-  OSNET  1.  Defense  Secure  Network  1  for  classified 
General  Service  (GENSER)  Messages. 

-  OSNET  2.  Worldwide  Command  and  Control  System 
(WWMCCS/Classif led  Messages) . 

-  DSNET  3.  Sensitive  Compartmented  Information 
(SCI/Classified  Messages) . 

*  OoO  Unclassified  Internet 

-  MILNET 

-  ARPANET 

Each  equipment  that  operates  on  DON  serves  a  double 
function:  first  as  a  general  purpose  Automatic  Data  Processing 
(AOP)  machine,  and  secondly  as  an  E-Mail  handler,  which  adds 
to  the  diversity  of  the  system.  [Ref.  2:p.  13} 

C.  THE  PKA8S8  OP  OKS 

The  phased  implementation,  as  designed  by  OfS  planners,  is 
Intended  to  deliver  the  message  directly  from  the  writer  to 
the  reader  by  gradually  pushing  the  so-called  AUTOOIN  *'line- 
of -demarcation” ,  currently  located  at  local  TCCs,  directly 
into  each  command.  This  evolutionary  transition  will  span 
nearly  20  years,  beginning  with  the  Baseline  system  of  1989, 
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and  culminating  with  the  Target  Architecture  by  the  year  2008. 
Figure  1  summarizes  the  more  significant  elements  of  the  DMS 
phased  evolution  [Ref.  5:p.  9]. 

DMS  Phased  Evolution 


I  M  ■  liM  M  I  I  M  N  ■  ii|  Iff  H  I  I 


Automate  TCC 
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Figure  l.  Sxiauaary  of  DMS  Phases 


1.  The  Baseline  (Maval  Systems  Bmpha&is) 

Figure  2  Illustrates  the  Baseline  Architecture  for  the 
DMS  which  has  two  main  elements,  the  AUTOOIN  for 
organizatJ  >nal  messages,  and  the  DON  E-Mail  service  fcr 
individual  messaging  [Ref.  l:p.  2-2].  Naval  organizational 
messaging  is  supported  by  the  linking  of  a  TCC  to  the  Naval 
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Communications  Processing  and  Routing  System  (NAVCOMPARS) , 
which  houses  the  Navy-operated  ASCs  and  provides  directory 
services  based  on  the  Message  Address  Directory  (MAD) . 

Processing  a  Naval  message  through  the  AUTODIN  system 
is  very  laborious  and  often  requires  additional  processing  at 
local  TCCs  on  either  an  LDMX,  a  Regional  Information  Exchange 
Terminal  (RIXT) ,  or  if  all  else  fails,  by  hand.  Once  these 
messages  arrive  at  this  "line-of-demarkation",  the  user  part 
of  the  baseline  messaging  system  ends,  and , additional  manual 
processing  and  routing  must  occur  before  the  message  reaches 
its  intended  destination. 

Individual  messaging  (E-Mail)  is  provided  via  the  DDN, 
with  directory  services  provided  by  the  Network  Information 
Center  (NIC).  The  Navy  currently  has  no  applicaUole  policy  or 
standards  established  to  cover  E-Mail  carried  over  the  DDN. 
[Ref.  5:p.  12] 

2.  Phase  I  (1989  -  1994) 

The  first  phase  emphasizes  the  automation  of  TCCs  in 
an  attempt  to  reduce  manning,  while  starting  the  push  to 
extend  the  messaging  system  to  the  users  [Ref.  l:p.  4-1].  To 
aid  in  this  automation,  the  DoD  plans  on  deploying  additional 
transitional  components  into  the  field,  such  as  AUTODIN 
directory  improvements,  AUTODIN  to  DDN  Interface  (ADI) 
capability,  and  the  transition  of  DDN  E-Mail  from  the  Simple 
Mail  Transfer  Protocol  (SMTP)  to  X.400  (MHS)  [Ref.  6]. 
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Finally,  during  this  period,  AUTODIN  data  traffic  will  begin 
to  migrate  to  the  DDM  for  transport  purposes  [Ref.  5:p.  32]. 

TCC  automation  promises  significemt  cost  savings  as  the 
DoD  will  be  able  to  plan  on  reducing  certain  manning 
requirements  of  TCC  which  is  characterized  by  l2d3or  intensive 
procedures  and  the  "hard  copy  message"  generations  to  provide 
Over-the-counter  (OTC)  services.  Currently,  there  are  PC- 
based  systems  available  that  will  allow  users  to  deliver  and 
receive  messages  via  diskette  media.  (The  HTF  Editor,  a  PC- 
based  messaging  systems,  will  be  covered  in  Chapter  IV.}  This 
state  of  the  art  computerized  automation  is  the  first  true 
step  toward  the  Intended  writer-to-reader  relationship  that 
DMS  planners  envisioned. 

Figure  3  depicts  the  proposed  DHS  Phase  1  architecture 
which,  for  the  first  time,  shows  an  AUTODIN-to-DDN  linkage 
[Ref.  7].  Of  special  noteworthiness  is  the  AUTODIN-DDN 
Interface  (ADI)  gateway  that  is  outlined  in  Figure  3  by  a 
dotted-line.  This  gateway  has  significant  security  problems 
because  it  will  link,  for  the  first  time,  the  AUTODIN,  a 
multi-level  secure  system,  to  DDN  which  does  not  currently 
meet  Defense  Communications  Agency  (DCA)  message  security 
requirements  [Ref.  6].  At  the  end  of  this  phase,  AUTODIN  and 
DDN  E-Mail  will  continue  to  act  as  separate  yet  interoperable 
systems  [Ref.  5:p.  33]. 
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3.  PhAS*  II  (1995  -  2000) 

Figure  4  represents  the  Phase  II  architecture  which  is 
scheduled  for  completion  by  the  year  2000  [Ref.  7].  During 
this  period,  tremendous  modifications  are  planned  that  will 
overhaul  DoD  messaging  such  as  [Ref.l:p.  4~3]: 

*  Accelerated  phaseout  of  TCCs. 

*  Combining  DSNET  and  MILNET  for  the  purpose  of 
inter-base  connectivity,  which  will  form  the  Secure 
Data  Network  System  (SDNS) ,  with  data  security  provided 
by  Message  Security  Protocol  (MSP) . 

*  Base  level  deployment  of  the  Installation  Information 
Transfer  Systems  (IITS) .  IITS  is  one  of  tlie  first  key 
elements  of  the  planned  Base  Information  Transfer 
System  (BITS)  and  will  lead  to  the  complete  phaseout 
of  TCCs  (BITS  planning  will  be  exeuained  in  Chapter 
III) . 

*  Installation  of  the  Organizational  User  Agents  (OUA) 
and  User  Agent  (UA)  as  defined  by  the  X. 400  protocol 
will  shift  message  transmission  and  receipt 
responsibilities  closer  to  the  user. 

*  An  Integrated  X.400  Message  Transfer  Agent  (HTA)  and 
X.500  directory  services  shall  be  completed. 

*  Phaseout  AMPEs  and  ASCs. 

The  use  of  International  standards  and  protocols  such 
as  Government  Open  Systems  Interconnection  Profile  (GOSIP) 
will  allow  tne  DoD  to  take  advantage  of  systems  and  softwares 
developed  by  industry,  as  opposed  to  having  everything 
customized  to  meet  "militarized”  specifications  (GOSIP  and 
X.400  will  be  discussed  in  Chapter  IV) .  This  new  computer  and 
communication  "systems"  development  mindset  goes  hand-in-hand 
with  current  DoD  purchasing  mandates  such  as  Commercial  Off- 
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the~Shelf  (COTS)  buying,  Non-Developmantal  Items  (NDI)  and 
Commodity  Purchasing  (CP) . 
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By  the  completion  of  Phase  II  the  foundations  of 
Integrated  Digital  Network  Services  (ISDN)  shall  be  laid  at 
the  base  level  (BITS) .  ISDN  teclinology,  which  sports  a 
relatively  large  bandwidth  and  high  data  transmission  rates, 
will  allow  the  ultimate  integration  of  voice,  data,  video  and 
narrative  messaging  via  one  transmission  media.  However  the 
Navy  still  has  ships  that  deploy  and  are  not  able  to  take 
advantage  of  the  larger  ISDN  bandwidth  using  present 
transmission  capabilities.  It  is  for  this  reason  that  special 
accommodations  for  fleet  interfaces  are  being  planned  that 
will  modify, the  large  "overhead"  required  to  transmit  X.400 
messages  so  that  "at-sea"  messaging  will  not  be  all  that  much 
different  from  that  being  performed  in  port. 

4.  Phase  XZZt  The  Target  hrehiteotuxe  (2001  -  2000) 

The  third  and  final  phase  of  the  DMS,  as  depicted  in 
Figure  5,  actually  begins  when  the  last  AUTODIN  ASC  is  finally 
phased  out  [Ref.  7].  During  this  phase,  the  local  and  long- 
haul  backbone  networks  will  be  fully  integrated  to  form  the 
Defense  Information  System  (DIS) .  The  piS  will  be  an  ISDN- 
based  global  network,  of  which  the  DMS  segment  will  continue 
to  be  the  SDNS.  Although  the  development  of  BITS  local  loops 
are  not  actually  part  of  the  DMS,  their  matiirity  along  with 
other  DMS  components  is  essential  for  the  successful 
completion  of  the  Department  of  the  Navy's  (DON)  portioh  •■^f 
the  overall  system  [Ref.  5:pp.  132-134]. 


17 


DMS  TARGET  ARCHITECTURE 
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Transition  frou  AUTOOIN  message  text  format,  known  as 
U.S.  Message  Text  Format  (USMTF) ,  to  the  X. 400-compatible 
Common  Message  Format  (CMF)  will  put  an  end  to  the  different 
styles  and  procedures  currently  used  to  generate  individual 
and  organizational  messages  [Ref.  l:pp.  4-3  -  4-4]. 

As  more  advanced  signaling  techniques  become 
implemented  on  ships  for  at-sea  users,  transmission  speeds 
great  enough  to  support  X.400  will  allow  complete  DMS 
messaging  availability  to  all  DoO  components.  (At-sea 
messaging  will  be  covered  in  Chapter  IV.}  Communications 
planners  anticipate  that  by  the  year  2008,  the  DMS,  as  it  is 
intended  today,  will  be  a  fully  operational  messaging  system 
for  the  DoD.  [Ref.  6] 

D.  CONCLUSION 


Th(!  underlying  drive  to  Implement  the  DMS  is  the 
requirement  to  increase  the  productivity  of  the  DoD  messaging 
sysjtem  while  trimming  a  considerable  amount  of  its  operating 
expanse. .  Cost  savings  and  service  improvements  are  always 
noble  goals  for  any  management  project.  A  quick  review  of  the 
phase  implementation  planning  of  the  DMS  reveals  that  while 
the  objectives  are  aggressive,  the  use  of  international 
standards  and  commercially  developed  automation  communication 
systems  and  components  will  go  a  long  way  in  meeting  these 
goals. 
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The  only  foreseeable  drawback  to  the  DMS  planning  is  that 
each  phase  is  closely  tied  to  one  another;  with  multiple  and 
overlapping  systems,  which  may  create  delays.  The  division 
between  phases  is  blurred  by  the  requirement  to  be  able  to 
link  the  new  with  the  old  at  all  times.  The  DoD's  track 
record  for  holding  onto  and  extending  the  service  life  of 
equipment  may  become  a  stumbling  block  to  IMS  planners. 
Finally,  by  placing  a  heavy  reliance  on  technological 
advancements  and  "other"  independent  yet  interoperable 
systems'  concurrent  development  (i.e.,  BITS,  ISDN  and  Fleet 
Interfaces) ,  the  intended  Target  Architecture  completion  by 
the  year  2008  may  be  a  difficult  mArk  to  hit. 


III.  DllfS  NETWORK  LINKAGE  TO  BASE-LEVEL  USERS:  BITS 

In  the  previous  chaipter,  network  jargon  was  used  to 
explain  the  implementation  planning  of  the  DMS  system,  i.e., 
ISDN,  GOSIP,  X.400  and  X.500.  The  scientific  definitions 
behind  this  network  terminology  are  beyond  the  scope  of  this 
thesis.  However,  a  fundzuaental  understanding  of  concepts 
surrounding  these  key  telecommunication/computer  technologies 
are  important  to  the  DMS/HiTS  user.  Therefore,  a  brief 
overview  of  several  significant  network  concepts  will  be 
presented  in  rhe  following  pages.  These  concepts  will  serve 
as  the  building  blocks  to  explain  the  linkage  between  DMS  and 
the  Base  Information  Transfer  System  (BITS) . 

A.  BIT8/DM8  NETWORK  TERMINOLOGY:  AN  OVERVIEW 

The  key  to  the  successful  implementation  of  the  DMS  system 
is  to  provide  a  computer-based  (digital) ,  high-speed  and 
inexpensive  transmission  medium  to  transmit  large  volximes  of 
data  (messages) .  In  communications,  the  measure  of 
transmission  capacity  is  euphemistically  kno%m  as  "the  size  of 
the  pipe".  In  the  past,,  the  DoD  had  been  shackled  to  a  very 
narrow  "pipe"  in  the  form  cf  copper  wire-line  and  radio 
(Microwave  Line-of-Sight  (LOS) ,  Satellite  Communications 
(SATCOMM)  or  High  Frequency  (HF) )  for  its  long-haul  messaging 
sysenrns,  all  of  which  are  based  on  slow  and  costly  analog 
methods  for  transmission. 
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with  the  advent  of  high  speed,  inexpensive  computing, 
coupled  with  tremendous  improvements  in  digital  transmission 
methods  and  rapidly  decreasing  prices  in  fiber  optic 
technologies,  we  now  have  access  to  networks  that  can  handle 
transmission  rates  in  the  millions  of  bits  per  second  (MBPS) . 
The  rtib  lies  in  the  fact  that  currently  there  are  smaller 
Local  Area  Networks  (LANs)  that  can  operate  at  rates  around 
100  MBPS,  and  when  they  and  other  communication  services 
(voice,  image,  data  and  video)  demand  integration,  the 
networks  will  require  tremendous  transmission  capacity  which 
is  not  currently  available.  This  is  where  technologies  based 
on  Integrated  Services  Digital  Network  (ISDN)  and  the  Open 
System  Integration  Reference  Model  (OSIRM)  begin  to  bridge  the 
gap  between  the  long-haul  networks  and  LANs,  or  the  DMS  and 
the  BITS. 

1.  ISOM 

The  BITS  architecture  will  be  built  around  the 

installation  of  ISDN  technologies  at  the  base-level.  ISDN  is 

^  set  of  telecommunications  rules  and  standards,  set  by  an 

international  communications  organization  known  as  CCITT.  The 

CCITT  defines  ISDN  as  [Ref.  8]: 

An  ISDN  is  a  network,  evolved  from  the  telephony 
Integrated  Digital  Network,  that  provides  an  end-to-end 
digital  .  connectivity,  based  on  CCITT  recommendations, 
supporting  a  wide  spectrum  of  user  needs  including  voice 
and  non-voice  services. 

End-to-end  digital  cpnnectivity  simply  means  that  if 
you  pick  upi  the  phone  in  your  office  and  make  a  call,  the 
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person  on  the  receiving  end  will  be  the  recipient  of  a  totally 
digital  transmission,  all  the  way  down  to  the  wire  that 
connects  the  phone  to  the  wall.  This  DoD'-wide  digital 
connectivity  is  what  BITS  and  the  CMS  are  banking  on  to 
provide  a  rapidly  maturing  worldwide  communications  baclcbone. 
ISDN  goes  well  beyond  mere  voice  communications  as  the  CCITT 
definition  implies.  Ultimately,  ISDN  will  provide  digital 
transmission  services  including  data,  text,  graphics,  music, 
video  and  voice,  all  of  which  will  be  integrated  through  one 
"pipe."  The  benefits  of  ISDN  are  in  the  following  three  areas 
[Ref.  9:p.  743]: 

*  International  standardized  services  for  world*>wide 
compatibility. 

*  User-to-network  interface  standardization  to  bring  down 
the  price  of  terminal  equipment  and  network  equipment, 
while  increasing  their  capabilities. 

*  Improved  network-to*>network  communication,  to  increase 
the  throughput  of  data  from  end-to-end. 

As  ISDN  technologies  take  root  around  the  world,  there 
are  industry  experts  that  claim  that  the  channel  architecture 
currei^tly  being  developed  is  too  restrictive  and  will  quickly 
become  inadequate  to  handle  the  data  rates  required  for  such 
things  as  High  Definition  Television  (HDTV)  and  100  MBPS  LANS. 
To  respond  to  these  critiques,  ISDN  is  looking  at  its  second 
generation,  known  as  Broadband  ISDN  (B-ISDN) ,  which  will 
provide  a  very  large  "pipe".  [Ref. 10] 
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2 .  081 


Computer  and  communication  technology  has  evolved 
quickly  over  the  last  few  decades,  and  recently  the  boundaries 
between  them  have  become  blurred.  Most  recently,  computer 
based  networks,  from  the  prevalent  PCs  to  the  powerful 
mainfrzunes,  have  become  the  communicator's  fare.  This  rapid 
growth  suffered  from  unregulated  growing  pains,  as  different 
networks  found  it  difficult  to  communicate  with  each  other. 
This  untenable  situation  prompted  the  International  Standards 
Organization  (ISO)  to  develop  an  architecture,  known  as  the 
Open  System  Interconnection  (OSI)  Reference  Model.  This  model 
defines  data  communications  standards  that  will  allow 
different  networks  to  interconnect.  [Ref.  ll:pp.  3-9  -  3-lC] 
The  OSI  Reference  Model  is  a  seven-layer  architectural 
structure,  with  each  layer  having  a  distinct  function.  Table 
I  is  an  illustration  of  the  layered  structure,  with  each 
layer's  specific  functions  defined.  The  concept  of  the 
layering  can  be  confusing,  but  the  premise  behind  it  is  simply 
to  provide  Industry  manufacturers  with  a  frame  of  reference  by 
which  they  can  build  their  systems  independently,  with  certain 
proprietary  bells  and  whistles,  while  conforming  to  OSI 
standards  to  provide  interconnection  capabilities  with  other 
systems.  [Ref.  9:pp.  15  -  18] 
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3.  OOSZP 

The  Federal  Inforaation  Processing  Standard  (FIPS)  146 
is  Bore  coBBonly  know  as  the  Govemaent  OSI  Profile  (GOSIP) . 
It  vas  established  to  provide  vendors  with  a  coBBon  set  of 
data  coBBiuiication  protocols  so  that  independently-developed 
systeBS,  produced  under  GOSIP,  can  interconnect.  As  of  August 
1990,  GOSIP  vas  designated  as  the  official  network  reference 
Bodel  for  all  US  govezruBent  agencies.  It  is  felt  that  by 
estBiblishing .  GOSIP  as  the  standard  protocol  suite,  the 
govemaent,  and  DoD  spscifically,  will  lead  the  way  in  pushing 
telecoBBunications  toward  international  network 
interconnectivity,  with  an  added  dividend  of  fair  and  open 
coapetition  between  vendors  (Ref.  ll:p.  3-1].  this  OoO-vide 
push  for  industry  acceptance  vas  given  a  "shot  in  the  ara" 
when,  late  in  1990,  the  Navy  issued  a  Request  For  Proposal 
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(RFP)  to  the  time  of  $75  Billion  for  the  first  GOSIP  products 
and  services  [Ref.  12:pp.  2  and  6]. 

The  earliest  versions  of  GOSIP  will  be  dealing  with 
the  many  and  varied  network  architectures  currently  fielded, 
by  the  use.  of  a  "gateway^  between  networks.  A  gateway  is  a 
networking  term  used  to  describe  a  device  (or  aerely  software) 
that  is  used  to  link  dissisilar  or  heterogeneous  networks  at 
the  "network  layer”  of  the  OSI  Reference  Model.  Its  next 
major  objective,  as  relevant  to  the  UMS,  is  the  transition 
froB  the  Simple  Mail  Transfer  Protocol  (SMTP) ,  currently  being 
used  on  the  DON,  to  the  X.400’’based  Message  Handling  System 
(MHS).  [Ref.  13:pp.  C-11  -  C-13  and  C-B-30) 

4.  Z.400/Z. 500  Protocols 

CCITT  has  defined  the  X.400  protocol  primarily  as  a 
Message  Handling  System  (MHS) .  A  MHS  is  used  for  transmitting 
electronic  messages  through  communication  systems,  end-to-end, 
from  the  Originator  to  the  reader.  The  MHS  is  comprised  of 
User  Agents  (UAs)  and  Message  Transfer  Agents  (MTAs) .  A  UA 
will  compose  a  message  at  the  originating  end  of  the  network, 
and  another  UA  at  the  receiving  end  will  accept  it.  Between 
these  UAs  will  be  one  or  more  MTAs  that  will  be  responsible 
for  the  transfer  of  the  message  from  one  UA  to  the  other, 
within  the  QMS  structure,  this  UA  (originator)  to  UA 
(receiver)  relationship  will  push  the  message  delivery 
function  past  the  "line  of  demarkatlon"  currently  in  place  in 
the  "baseline"  AUTODIN  system.  [Ref.  13 :p.  C-D-8] 


The  CCITT  X.500  standard  defines  a  directory  service 
which  will  provide  a  user-friendly  nanlng  and  nase-to-address 
sapping  fiinctionality  [Ref.  12:p.  C-D-9].  Sisplistically, 
this  seans  that  if  a  DMS  systes  user  would  like  to  send  a 
sessage  to  their  college  professors,  Dr.  Suh  and  Dr.  Boger, 
the  originating  UA  merely  accesses  the  X.500  directory  and 
addresses  this  salutation  "TO:  Dr.  Suh  and  Dr.  Boger”,  the 
directory  will  then  fill  in  the  actiuil  network  address  and 
send  it  on  its  way. 

This  MHS  proaises  to  provide  data  security,  message 
store-and-forward  functions,  access  to  worldwide  directories 
of  users  via  the  X.500  directory  services,  and  international 
network  connectivity  under  the  auspices  of  the  GOSIP  protocols 
[Ref.  14:  pp  48,  60  and  63].  These  protocols  are  not  without 
their  faults  as  they  retire  a  very  large  "pipe”  with  fast 
data  rates  to  push  a  message,  wrapped  in  an  X.400  envelope, 
through  the  system.  This  tremendous  amount  of  data  "overhead” 
is  currently  one  of  the  major  restricting  factors  to  the  full 
implementation  of  the  DMS  to  all  users,  namely  the  Naval  at- 
sea  subscribers  [Ref. 6]. 

B.  BITS  ABCHZTBCTUBB 

The  DMS  requirement  for  base-level  connectivity  compelled 
each  branch  of  the  DoD  to  develop  ISDN/GOSIP  upgrades  for  all 
their  facilities.  For  the  Department  of  the  Navy  (DON) ,  the 
responsibility  was  delegated  to  the  Commander,  Naval  Computers 
and  Telecommunications  Command  (NCTC)  for  systems  concept 
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d«velopnent,  testing  and  installation  [Ref.  5:p.  110].  From 
the  initial  planning  came  the  BITS  program,  under  the  aegis  of 
the  Telephone  Modernization  Plan  (TMP) .  The  TMP  was  a  key 
element  of  the  Navy  Data  CozoBunications  Control  Architecture 
(NDCCA)  which,  in  1988,  separated  Naval  data  conaiinications 
into  three  stib^architectures,  of  which  the  base-level  (BITS) 
was  one  [Ref.  ll:pp.  3-7  -  3-9].  The  underlying  motivation 
for  NDCCA  was  that,  although  most  base-level  telephone  systems 
were  adequate,  they  lacked  standardization  and  were  prone  to 
costly  failures.  The  goal  was  to  both  modernize  and  institute 
international  standards  in  these  new  BITS  systems,  thereby 
taking  advantage  of  ISDN  innovations  and  meeting  DoD-dlrected 
GOSIP  requirements. 

1.  BITS  Objective 

The  principle  objective  of  the  BITS  architecture  was 
to  provide  base-level  Integrated  network  management  with 
worldwide  interoperability  and  connectivity.  The  BITS  system 
quickly  became  locked  into  the  phased  implementation  planning 
of  the  DMS  architecture  since  iBfS  is  one  of  the  services 
available  through  ISDN  modernization.  Other  BITS  objectives 
included: 

*  service  availability  upon  demand. 

*  Network  integrity  —  as  measured  by  the  system's  ability 
to  send  and  receive  without  introducing  errors  above  an 
acceptablf  level. 

*  System  reliability  —  by  the  use  of  redundant  and 
modular  systems.  This  reliability  will  also  be 
facilitated  by  the  Implementation  of  GOSIP  standards. 


*  Serviceability  —  also  provided  through  nodular  and 
redundant  design. 

The  successful  fulflllnent  of  the  BITS  objectives  will  allow 
each  base-level  I»fS/BITS  user  access  to  a  st2mdardized  and 
transparent  network  that  neets  all  DoO  GOSIP  requirements, 
whi7.e  providing  ISDN  services  integrating  voice,  messaging, 
data,  inaging  and  video.  [Ref.  13:pp.  C-27  -  C-30] 

2.  Planniag  Phases 

In  Decenber  1986,  the  Chief  of  Naval  Operations  (CNO) 
directed  the  Naval  Data  Automation  Command  (NAVDAC)  to  develop 
a  procedure  that  could  be  used  as  a  standard  throughout  the 
Navy  for  BITS  implementation.  This  CNO  tasking  resulted  in  the 
BITS  Requirements  Identification  and  Planning  Program.  This 
central  planning  effort  was  Instituted  to  provide  for 
standardization  and  projected  cost  savings  by  virtue  of  their 
market  buying  leverage.  [Ref.  13:p.  C-3] 

Under  NAVDAC's  guidance,  each  base  would  develop  a 
customized  Base  Communications  Plan  (BCP)  which  would  identify 
and  account  for  interbuilding  and  interactivity 
communications,  all  the  way  down  tb  the  waterfront.  Once 
completed,  the  BCP  will  then  be  turned  over  to  the  NCTC 
commercial  buying  facility  which  will  then  design  a  BITS 
Modernization  Plan.  This  modernization  plan  will  then  be 
developed  into  a  Request  For  Proposals  (RFPs)  to  solicit 
contract  bids  from  the  private  sector.  The  overall  BITS 
planning  and  development  process  will  pass  through  the 
following  phases:  [Ref.  13:pp.  C-4  -  C-6] 


*  Phase  I  (baseline) :  Each  base  identifies  a  BITS  point 
of  contact  who  coordinates  all  efforts  in  the 
development  of  the  initial  Life  Cycle  Management  (LCM) 
documents.  This  is  the  first  step  in  any  major  DoD 
acquisition  program. 

*  Phase  II:  Each  base  develops  a  BCP  with  the  assistance 
of  NAVDAC  under  the  direction  of  the  base  commanding 
officer. 

*  Phase  III:  Technical  specifications  are  drawn  to  meet 
all  OoD  requirements  with  guidance  from  OPNAVINST 
2800.3. 

*  Phase  IV:  The  contracting  officer  releases  the  RFP  and 
the  contract  is  awarded. 

*  Phase  V:  BITS  is  installed  and  tested. 

It  is  forecasted  that  the  majority  of  the  Naval  bases 
will  have  completed  the  Initial  BITS  installation  sometime 
after  1996  which  will  meet  OHS  phase  I  mandates;  however, , it 
is  not  expected  that  this  will  mean  total  ISDN  conversion. 
ISDN  technologies  will  be  implemented  as  they  become  available 
and  will  be  used  as  the  basis  for  intrabase  data  transport 
among  DMS  processing  equipment  and  ADP  equipment,  and  will 
provide  interbase  (off  base)  connectivity.  As  ISDN  matures, 
the  Navy  plans  on  its  Implementation  to  meet  the  needs  ot 
1^'s  Phase  III  high  data  rate  requirements  by  the  year  2008. 
[Ref.  13 :p.  C-66] 

Although  BITS  is  a  Navy  program,  it  is  also  required 
to  interface  with  boD  programs  such  as  the  IBiS,  SDNS  and 
finally  the  DIN.  The  l»fS  program  requires  joint  DoD  programs 
to  monitor  its  worldwide  progress  and  to  insure  total 
interoperability.  There  must  be  close  ti3s  between  the  DoN- 
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level  BITS  and  the  DoD-level  Z»fS;  especially  when  dealing  with 
the  X.400  MHS  and  X.500  Directory  Service  phase-in. 

3.  Network  Security 

As  networks  have  evolved  over  the  past  ten  years,  so 
have  their  security  problems.  Nowhere  is  the  problem  of 
network  security  more  critical  than  in  a  DoD  communication 
system.  The  protection  of  military  messages  (data), 
classified  or  xuiclassified,  is  of  the  utmost  concern  for  both 
the  DMS  and  BITS  designers.  The  protection  of  a  network  goes 
well  beyond  mere  data  security  as  the  physical  integrity  of 
the  cabling  and  equipment  loom  at  the  forefront  of  any  DoO 
security  officer's  planning. 

As  a  culmination  of  the  combined  efforts  of  private 
industry,  academia  and  the  DoO,  the  National  Computer  Security 
Center  (HCSC)  has  established  a  specific  set  of  computer 
system  security  evaluation  criteria  in  a  publication  known  as 
"the  orange  book",  so  named  for  the  color  of  its  cover.  The 
criteria  were  intended  to  be  used  as  an  assessment  tool  for 
the  evaluation  of  security  attributes  of  any  computer/ 
communication  system,  and  has  recently  become  the  standard  by 
which  security  requirements  and  accreditation  have  been 
dictated.  As  Table  II  illustrates,  the  NSCS  security  criteria 
are  organized  into  four  divisions  ranging  from  A  to  D,  with  A 
being  the  most  secure  division  [Ref.  15:pp.  260  •  263].  Each 
division  is  further  segmented  into  classes,  luid  it  is  by  these 
class  categories  that  most  systems  are  evaluated. 


TABLE  II. 

M8C8  "ORANGE  BOOK"  8BC0RITY  CLA88IFICATI0N8 


Guided  by  the  NSuS  evaluation  criteria,  DoN  has  drawn  up 
specific  security  requirements  for  all  their  new  computer  and 
communications  systems  [Ref.  13:p.  C-'Sl]: 

*  Protection  of  unclassified  yet  sensitive  information. 

*  Data  aggregation  and  inference  control,  and  protection 
of  ship  movement  information. 

*  Changes  in  operational  environment/scenario. 

*  Separation  of  classified  and  unclassified  data. 

*  Sufficient  network  controls  to  meet  NSCS 
accreditation. 

*  All  unclassified  networks  will  meet  at  least  NSCS  Class 
C2  level  requirements. 

*  All  classified  networks  will  meet  at  least  NSCS  Class 
B2  level  requirements. 

*  All  gateways  will  meet  at  least  the  NSCS  Class  B3 
level  requirements. 


rhe  target  security  architecture  for  the,  BITS  system 
is  similar  in  design  to  the  National  Security  Agency's  (NSA) 
proposed  SDNS.  SDNS  is  the  DoD  messaging  network  scheduled  to 
replace  DDN. 

The  SDNS  will  use  NSA-provided,  high-grade  cryptographic 
algorithms  for  data  encryption  and  traffic  key  generation 
to  assure  confidentiality  of  communications.  State-of- 
the-art  key  management  techniques  will  be  used  to  minimize 
the  burden  associated  with  generation,  distribution, 
accounting,  and  control  of  classified  key  in  physical 
form.  [Ref.  13 :p.  C-55] 

The  BITS  network  will  be  designed  around  cryptographic 
protection  via  concepts  known  as  end-to-end  encryption  (E^) 
and  BLACKER.  For  example,  E*^  security  is  similar  to  the 
encryption  methods  that  protect  current  messages  being 
transmitted  from  ship-to-shore.  If  the  encrypted  message  was 
intercepted  by  some  unauthorized  source  it  would  be  very 
difficult  to  decipher  in  a  timely  fashion.  The  BLACKER 

program  is  being  developed  to  support  multilevel  security 

! 

systems,  specifically  for  networks  such  as  DNS  and  BITS.  [Ref. 
13:pp.  C-51  -  C-56] 

4.  BITS  Architecture 

The  foundation  of  the  BITS  architecture  is  b£ised  on 
several  components  such  as  an  ISDN-compatible  backbone  ced^le 
plant,  an  ISDN  switching  complex  and  network  gateways.  These 
will  be  used  as  a  Navy-wide  standard  upgrade  to  illow  a 
uniform  migration  toward  the  BITS  Target  Architecture  b]^  1994 . 

The  BITS  Target  Architecture,  as  illustrated  in  Figure 
6,  will  be  configured  in  such  a  way  that  all  base  elements. 
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including  ships  that  are  pier-side,  will  be  interconnected  to 
an  ISDN  switching  complex  and  cable  plant  [Ref.  13 :p.  C-30]. 
From  the  switching  complex,  the  BITS  network  will  interface 
with  the  DoD  3ong-haul  cosoatinications  system  (currently  DDN 
and  AUTCVON) .  The  switching,  monitoring  <£nd  billing  of  the 
entire  system  will  be  controlled  by  a  Network  Management 
Center  (NMC)  which  will  soon  be  replacing  TCCs  as  the  primary 
communications  element  at  each  base. 

The  base  switch  complex  will  be  the  key  to  the  BITS 
transition  due  to  the  mix  of  private  switches  and  equipment 
currently  in  use  on  many  bases.  This  switching  center  will  be 
the  location  on  base  where  all  services  will  be  integrated  and 
distributed  for  either  intrabase  (on  base)  or  interbase  (off 
base)  connectivity.  To  date,  the  technology  critical  to 
achieving  a  low-cost,  efficient  integrated  switch  is  limited 
and,  therefore,  remains  as  a  sttunbling  block  for  BITS 
planners.  [Ref.  13 ;p.  C-34) 


The  transmission  media  options  that  are  being 
considered  to  provide  the  base  baclcbone  cable  plant  are  the 
currently  installed  copper  twisted-pair  wiring,  a  total  base 
retrofit  with  fiber-optic  cabling  or  a  combination  of  the  two. 
These  media  will  be  required  to  meet  international  ISDN 
standards  and  will  b«  connected  to  all  users  to  provide  the 
base-wide  and  DoO-wide  network  services. 

Pier-side  interconnection  between  a  shore-based  system 
and  a  ship  at  the  pier  is  unique,  in  that  currently  telephone 
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service  is  provided  by  the  base  system  while  messaging  (data) 
is  not  handled  via  ah  intrabase  exchange.  The  fact  that  ships 
at  sea  will  be  using  their  own  means  for  the  transmission  of 
both  voice  and  messages  further  complicates  the  situation,  as 
one  communication  system  is  required  for  ships  in  port  to 
interface  with  BITS  and  another  is  required  for  those  at  sea. 
The  difference  in  bandwidth  requirements  alone  is  critical  to 
both  the  I»IS  and  BITS  implementation.  In  the  interim,  current 
Naval  messaging  systems  will  retain  most  of  the  responsibility 
for  message  delivery  to  ships  either  at  sea  or  in  port.  The 
target  for  a  fully  operational  ISDN  pier-side  connection  will 
be  to  provide  connectivity  to  the  DMS  via  the  BITS  with 
sufficient  bandwidth  for  both  voice  and  data  services  by  the 
year  2001  (DMS  Phase  III).  [Ref.  13:p.  C-31] 

The  Network  Management  Center  (NMC)  will  be  the  center 
of  the  BITS  system  as  it  attempts  to  meet  the  needs  of  a 
diverse  group  of  base  users.  The  interface  of  the  base 
network  to  the  pier-side  »lone  is  like  providing  flexible 
service  capacity  to  several  floating  cities  whose  operating 
schedules  make  their  arrival  and  departure  totally 
unpredictable.  This  large  traffic  variation  will  be  managed 
through  the  NMC  automated  management  resources  and  automated 
communications  switches. 

C.  COMCLUSXOll 

As  integrated  services  become  available  through  BITS 
implementation »  the  control  and  management  of  theso  services 
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within  each  base  will  become  more  emd  more  complex.  The 
requirement  for  the  maintenance  of  the  base's  portion  of  the 
DMS  X. 400  MHS  and  X.500  directory,  combined  with  a  full  range 
of  BITS  support  fiinctions,  will  require  a  fully-staffed  and 
automated  NMC.  Currently,  there  is  no  NHC-equivalent  on  most 
bases,  with  the  only  facilities  even  close  in  fvmctionality 
being  the  Naval  Telecommunication  Centers  (NTCCs)  which 
provide  AUTODIN  connectivity  to  the  base  subscribers.  Phone 
services  are  provided  by  a.  "mixed-bag"  of  Private  Branch 
Exchange  (PBX)  equipment  and  wire-line  services,  which  are 
normally  managed  and  maintained  by  local  telephone  companies 
or  telecommunications  equipment  vendors.  It  seems  that  the 
cost  savings  derived  from  the  reduction  of  manning  and 
antiquated  equipment  at  base  NTCCs,  as  envisioned  by  DMS 
planners,  will  be  partially  absorbed  by  the  BITS  requirements 
for  NMC  staffing  and  network  equipment. 
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ZV.  AUTOMXTED  SHIPBOASD  MS88AGZHO:  AM  EVOLUTION 

In  the  previous  chapter,  it  was  explained  that  one  of  the 
most  difficult  aspects  concerning  both  the  INfS  and  BITS 
planners  was  the  shipboard  interface.  While  in  port,  ships 
might  be  able  to  link  directly  into  the  intended  base  network 
(BITS) .  But,  when  they  get  underway,  there  remains  a 
transmission  capacity  problem  that  cannot  quickly  be 
dismissed.  This  chapter  will  concentrate  on  the  various 
systems  that  are  currently  being  developed  to  bridge  the  gap 
between  the  manually-intensive  shipboard  messaging  systems 
currently  in  use  and  the  systems  meeting  the  degree  of 
automation  required  to  satisfy  DMS  architectural  demands. 

A.  CUSBENT  8BZPBOARO  MESSAOINO  SY8TEM8 

At  present,  there  are  several  methods  used  to  process 
messages  onboard i  ships,  ranging  from  pen-and-ink  message 
drafting  to  computer-assisted  processing  and  routing  systems. 
Most  ships  are  us  Lng  two  procedures  for  messaging:  a  slow  ahd 
labor-intensive  system  while  in  port  and  a  rudimentary 
computerized  system  while  at  sea.  The  determination  as  to 
whether  a  ship  is  to  have  an  elaborate  computerized  messaging 
system  is  based  cn  mission  requirements  and  cost.  With  the 
advent  of  inexpensive  and  highly-efficient  PCs  and  "user 
friendly"  word  proqeseing.  software,  the  gap  between  the 
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"have's"  and  "have  net's*  in  autoaated  aessage  processing  has 
narrowed. 

1.  Za  Port  Messaging 

The  vast  majority  of  the  fleet  still  uses  pen-and-inX 
message  drafting  while  in  port.  These  drafts  are  routed 
through  the  ship's  chain-of-commemd  until  they  reach  the 
person  with  message  releasing  authority,  «dso  is  usually  the 
commanding  officer.  By  the  time  the  message  has  been  passed 
through  this  gauntlet,  kno%m  as  "the  chop-chain",  the  draft  is 
nearly  unintelligible  due  to  the  line-outs  and  re%rrites  that 
clutter  the  page. 

A  releasable  message  will  now  be  passed  to  the  ship's 
Radioman,  who  will  retype  it  on  a  standardized  DoD  form  known 
as  a  "DO-173",  with  a  special  Optical  Character  Read2d>le  (OCR) 
type  setting.  Special  processing  codes  will  be  assigned,  and 
the  message  will  be  routed  for  final  release.  This  labor- 
intensive  process  usually  goes  through  several  iterations  due 
to  typing  or  formatting  errors  before  the  message  leaves  the 
ship.  Unfortunately,  the  message  is  not  yet  in  the 
communication  system  because  it  must  now  be  hand-delivered  to 
the  local  communication  center  (NTCC) .  Zt  is  at  the  NTCC  that 
the  message  will  be  input  into  the  messaging  system  via  an 
optical  scanner.  Usually  there  are  errors  introduced  into 
the  system  during  the  scanning  process,  and  these,  if  not 
caught  initially,  will  slow  the  system  downstream,  as  an 
operator  will  have  to  manually  reprocess  the  message  before  it 
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reaches  its  destination.  Once  it  arrives  at  the  destination 
NTCC,  it  will  be  processed  and  hand-carried  to  its  intended 
addressee. 

As  desktop  conputers  began  to  appear  in  the  fleet 
during  the  aid-’to-late  80s,  the  Marine  Corps  began  development 
of  message  generation  software  knotm  as  Message  Text  Format 
(MTF)  Editor.  The  MTF  Editor  is  an  easy-to-use  message 
preparation  software  package  that  allows  a  message  drafter  to 
create,  format  and  transmit  United  States  Message  Text  Format 
(USMTF)  formatted  messages.  The  MTF  Editor  is  designed  to  run 
on  an  IBM  compatible  PC.  With  special  devices  sUch  as  a  paper 
tape  punch  or  an  OCR  "daisy-wheel**  printer,  it  can 
significantly  reduce  the  degree  of  manual  processing  that  was 
required  by  the  old  system.  [Ref.  5:p.  47] 

The  most  recent  release  of  MTF  Editor  includes  a 
"floppy"  diskette  read-and-%nrite  capability.  This  function 
was  developed  to  meet  the  DMS  Phase  I  requirement  for  diskette 
message  delivery  and  receipt  at  local  NTCCs.  By  delivering 
messages  to  the  MTCC  via  a  diskette,  error-prone  optical 
scanners  will  quickly  become  a  thing  of  the  past.  This 
message  automation  capability  is  very  cost  efficient  because 
it  does  not  require  a  dedicated  computer  system  to  run  it. 

An  interesting  linkage  has  developed  between  the  BITS 
and  DKS  systems  as  a  result  of  the  MTF  Editor's  "next 
generation"  which  is  planning  a  modem  or  gateway  Interface 
that  will  allow  messages  to  be  sent  to  and  received  from  the 
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HTCC  •l«ctronically,  and  tharaby  aliainating  tha  hand- 
dallvaxy  raquirad  in  tha  prasant  ayatas  [Raf .  16] .  Thia 
alectronic  delivary  of  aaaaages  ia  an  added  bonus  and  was  not 
in  tha  original  CMS  or  BITS  planning. 

2.  At-8aa  Masaaging 

Ships  at  saa  ara  connactad  to  tha  AUT00I17  via  several 
Navy-oparatad  comunlcationa  stations,  known  as  HAVCAMS  (see 
Chapter  II) .  This  connection  is  established  by  the  Naval 
Cosputar  Processing  and  Routing  System  (NAVCOMPARS) . 
NAVCOMPARS  routes  messages  between  tha  shore-based  AUTODIN  and 
at-sea  subscribers  equipped  with  tha  Naval  Modular  Automated 
Communications  Svibsystem  (NAVMACS)  via  HP  massage  broadcasts 
(kno%m  as  a  Full  Period  Termination)  and  Pleat  Satellite 
Broadcast  (PSB)  (satellite  massage  transmission  for  ship  at 
saa) .  Tha  NAVCOMPARS  has  automated  several  functions  that 
allow  efficient  delivery  and  receipt  of  fleet  messages.  Among 
the  automsted  functions  are:  [Ref.  17:pp.  66  -  67] 

*  Maintaining  a  real  time  locator  of  fleet  users. 

*  Formatting,  screening,  and  distributing  messages  for 
both  local  and  remote  subscribers. 

*  Providing  termination  (receipt)  of  ship-to-shore 
messaging  circuits. 

*  Housing  tha  primary  interface  with  the  NAVMACS  afloat 
satellite  messaging  system,  known  as  the  Common  User 
Digital  Information  Exchange  System  (CUDIX) . 

The  satellite-based  linkage  for  the  ship-to-shore 
messaging  is  provided  by  NAVMACS/CUDIXS  systems.  This 
computerized  communications  equipment  was  developed  in  1975  to 
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take  advantage  of  the  first  fleet  coniiiunicatlon  satellites  In 
orbit.  The  CUDIXS  receives  Its  Input  fron  the  NAVCOMPARS  and 
rekeys  (retransmits)  ell  messages  addressed  to  the  fleet  at- 
sea  users.  The  NAVHACS  Is  a  family  of  shipboard  systems 
ranging  from  the  antiquated  V(l)  variant  to  the  relatively 
powerful  V(5A) .  Today,  over  90%  of  the  fleet  has  NAVHACS 
Installed,  with  the  goal  of  Navy-wide  coverage  by  the  end  of 
1992. 

NAVHACS  was  designed  to  automate  at-sea  shipboard 
messaging,  and  to  Its  credit,  most  communicators  cannot 
Imagine  being  without  It.  However,  NAVHACS  Is  slow  and 
expensive  compared  to  today's  modem  computers.  NAVHACS 
pilanners  have  been  upgrading  as  many  ships  as  possible  with 
later  variants  as  they  become  available;  unfortunately,  these 
will  not  meet  the  fleet  automation  needs  according  to  the  DMS 
requirements. 

The  latest  NAVHACS  variant,  V(5A) ,  Is  a  shipboard 
networked  messaging  system,  with  Its  computerized  foundation 
being  two  UNISYS-bullt  AN/XjyK-44  (nicknamed  ••YUK-44'*) 
computers.  The  AN/UYX-44  Is  based  on  1975  computer  technology 
and,  due  to  Its  hlghprlce.  Is  limited  to  such  high-value  ships 
as  aircraft  c-.^  triers  and  large  amphibious  ships. 
Unfortunately,  only  the  NAVHACS  V(5A)  is  operational  during 
normal  inport  periods  (the  other  NAVHACS  variants  only  operate 
In  port  for  a  short  period  before  and  after  getting  underway) 
and  must  operate  with  all  of  its  radio  transmission  and 
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mceiving  •guipment.  This  procedur*  is  very  cost  intensive 
due  to  the  extra  Banning  reguirenents,  and  environmentally 
guestloned}le  because  of  the  electronagnetic  radiation  that  is 
inherent  in  radio  transmission.  Radiomen  aumning  the  "Radio- 
Shack”  on  these  ships  would  be  more  willing  to  power-down 
their  communications  gear  if  there  were  a  system  that  could 
more  efficiently  handle  their  message  reguirements. 
Unfortunately,  the  V(5A)  is  not  designed  for  a  pier-side 
network  Interface  as  reguired  by  the  BITS  architecture,  but 
iinder  the  Copernicus  architecture  (discussed  later  in  this 
chapter)  there  is  help  coming.  [Ref.  18] 

t 

B.  BOW  00  WB  OST  TBBRB  TBOM  BBSS? 

Designers  for  contemporary  shipboard  communication  system 
are  working  on  LANs  and  the  new  generations  of  communication 
suites  to  meet  the  demands  of  messaging  subscribers  at-sea, 
and  to  assure  interoperability  with  the  DKS  system. 

1.  Shipboard  LAB:  SArBBET  12 

One  of  the  major  progreuns  that  the  Navy  has  been 
working  on  to  integrate  shipboard  communication  services  is 
the  SAFENET  II  system.  The  SAFENET  II  is  the  second  in  the 
series  of  shipboard  network  technologies  using  fiber  optics. 
In  an  attempt  to  save  time  and  money  by  the  use  of  industry- 
developed  technologies,  its  design  is  based  on  the  American 
National  Standard  Institute  (ANSI)  standard  known  as  Fiber 
Distributed  Data  Interface  (FDDI) . 
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The  FDDI  network  standard  was  chosen  because  of  its 
transmission  bandwidth  capacity,  reliedsility  and  cost  of 
technology.  It  is  also  the  standard  of  choice  by  BITS  network 
designers  because  FDOI  provides  redundancy,  via  dual  fiber 
optic  rings,  and  security,  since  it  is  not  easy  to  tap  into  a 
fiber  optic  cable  without  disrupting  the  transmission  bit- 
stream  [Raf.  19:p.  189]. 

Without  getting  into  an  overly  complex  study  of 
network  technologies,  the  following  will  provide  an  overview 
of  the  basic  concept  behind  FDOI.  An  FDDI -based  network  uses 
a  token-passing  dual  ring  architecture.  The  token  is  a  unique 
series  of  bits  circulating  around  the  network.  A  node  (user) 
wishing  to  transmit  on  the  network  must  wait  until  it  captures 
the  token  before  transmitting.  Once  the  token  is  captured, 
the  node  can  start  transmitting  the  message.  The  token  is 
released  back  at  the  end  of  the  transmission.  The  message 
travels  around  the  network  \mtil  it  returns  back  to  tha 
originating  node.  As  the  message  travels  around  the  ring,  the 
intended  addressee  of  the  message  will  receive  it  and  pass  it 
on  its  way.  This  accomplishes  two  things:  first,  the  fact 
that  tha  token  returned  to  the  originator  ensures  that  the 
ring  is  intact,  and  secondly,  it  provides  acknowledgement  to 
the  originator.  The  dual-ring  architecture,  as  depicted  in 
Figure  7,  provides  the  redundancy  required  in  any  vital 
shipboard  communication  system  [Ref.  20:p.,16].  If  a  node  in 
the  ring  were  to  go  off-line  or  the  ring  were  to  be  severed, 
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the  backup  ring  would  allow  the  rerouting  of  the  message.  All 
of  these  features  are  transparent  to  the  network  user.  The 
FDDI  system  is  designed  to  operate  at  transmission  speeds  of 
100  MBPS.  [Ref.  19:pp.  187-193] 

Specifically,  SAFENET  II  is  ideally  suited  for  the 
DMS/BITS  in-port  ship-to-pier,  and  at-sea  ship-to-shore 
communication  interfaces,  because  it  conforms  to  the  OSI 
standards  and  avoids  the  ad  hoc  retrofitting  prevalent  in  many 
messaging  systems.  Along  with  the  benefits  associated  with 
the  OSI  (or  GOSIP)  protocols,  come  the  detriments.  That  is, 
not  all  GOSIP  standards  have  been  clearly  defined;  and,  though 
private  industry  is  gearing  up  to  provide  OSI  products,  there 
is  very  little  "on  the  shelf"  at  this  time. 
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Figure  7.  FDDI/8AFEMET  IZ  Dual-Ring  XAM 


To  date,  only  a  prototype  of  SAFENET  exists,  as 
developers  at  the  Naval  Oceans  System  Command  (NOSC)  attempt 
to  work  out  the  "bugs"  and  design  a  simple  and  cost  effectiye 
method  to  install  it  in  the  fleet.  The  present  plan  of  action 
is  to  try  to  sell  the  Navy  on  wiring  SAFENET  directly  into  new 
construction  ships  and  merely  retrofitting  a  selected  number 
of  newer  ships.  This  plan  is  prudent  insofaras  DMS  planning 
documents  are  not  calling  for  a  true  shipboard  interface  until 
the  year  2001.  [Ref.  20:p.  15] 

2.  The  Future:  Copernicus 

In  1543,  Copernicus  put  forth  that  the  sun,  and  not 
earth,  was  the  center  of  the  universe.  His  vision  inspired 
the  Navy  to  christen  its  new  commtinication  architecture  in  his 
name.  The  essence  of  the  Copernicus  architecture,  as  it 
applies  to  the  shipboard  environment,  is  to  bring  multiple 
communication  services  together  into  one  system.  [Ref.  21] 

Currently,  there  is  tremendous  competition  for  the 
limited  space  in  the  ship's  Radio  Shack  which  is  a  result  of 
the  independent  equipment  that  supports  a  score  of  tactical 
and  strategic  communications  systems.  Copernicus  will  striye 
to  eliminate  the  need  for  customized  pieces  of  equipment,  the 
only  mission  of  which  is  to  control  but  one  or  two  circuits. 
To  accomplish  this,  the  Navy  must  abandon  the  way  it  has 
developed  communications  systems  in  the  past,  which  has 
resulted  in  delays  from  five  to  fifteen  yea^rs  (e.g.,  NAVMACS) . 
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The  rate  of  change  in  technology  is  already  accelerating 
before  our  eyes.  The  downside  is  prograimiatic;  the 
generation  length  for  a  microcomputer  is  now  less  th2m  the 
average  tour  length  of  Navy  men  and  women  anu  ine-third 
the  length  of  the  average  acquisition  cycle.  [Ref. 

21:p.  86] 

In  the  spring  of  1990,  the  CNO  authorized  the 
migration  of  NAVMACS  functionality  from  the  current  AN/UYK 
series  computer  systems  to  commercially-available  PCs  under 
the  Copernicus  architecture  [Ref.  22] .  This  decision  was 
based  on  the  fact  that  the  NAVMACS  program,  though  adequate 
for  the  present  time,  1  :>cked  the  flexibility  to  expand  to  meet 
future  shipboard  communication  needs. 

Table  III  outlines  projected  cost  savings  resulting 
from  the  replacement  of  NAVMACS  systems  with  the  Navy  Standard 
Desktop  Tactical  Computer  2  (DTC-2}.  It  is  assumed  that  all 
ships  including  those  not  currently  having  the  latest  variant 
of  the  AN/UYK  computer  are  to  be  upgraded  [Refs.  18  and  22]. 
The  DTC-2  used  in  this  comparison  is  a  SUN  4/110  workstation 
equipped  with  a  300MB  hard  disk,  color  monitor.  Tempest 
certified  high-speed  printer,  system  software  and  Motorola 
88000  processor  [Ref.  22]. 

The  potential  for  cost  savings  is  obvious,  but  what  is 
even  more  significant  is  that,  wit!  the.  use  of  the  continually 
evolving  PC  in  the  system,  NAVMACS  can  quickly  extend  itself 
to  facilitate  both  at:-sea  and  in  port  messaging.  An  added 
benefit  derived  from  the  use  of  PCs  is  the  fact  that  they  are 
modular  and  easy  to  upgrade.  The  main  criticism  is  that  the 
standard  "garden  variety"  PC  may  not  be  rugged  enough  for 
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TABLE  III 

NAVMACS  MIGRATION  COMPARISON 


NAVMACS 

SHIP  UYK- 

44  UPGRADE  DT-2  CONVERSION 

VARIANT 

NUMBERS  ($) Million 

($)Mlllion 

VI 

93 

17.67 

3.72 

V2 

324 

61.56 

12.96 

V3 

74 

14.06 

2.96 

V5 

35 

N/A 

1.4 

V5A 

47 

N/A 

1.68 

SUBTOTAL 

99.29 

2i.92‘ 

DIFFERENCE 

Q. 

76,370,000.00j 

Desk  Top 

2  «DT-2)  Mod. 

version 

6  $  40,000.  ea. 

AN/UIK-44 

0  $  190, 000 .  ea. 

full-time  message  processing.  Therefore  certain  components 
must  be  hardened  so  as  not  to  break  down  under  heavy  use.  For 
the  most  part,  these  critiques  have  been  answered  by  the  mere 
fact  that  PCs  have  been  at  sea  for  over  ten  years  and  have 
performed  adequately  thus  far. 

Over  the  past  few  years,  designers  at  the  Space  and 
Naval  Warfare  Systems  (SPAWARS)  Command  have  been  working  on 
ways  to  Integrate  PCs  onto  ships.  Thesa  efforts  were  provided 
with  extra  emphasis  recently  because  of  the  emergent  DMS 
requirements.  In  an  attempt  to  develop  emulation  software 
that  would  allow  the  current  NAVMACS  system  to  act  like  a  PC 
and  simultaneously  link  into  a  SAFENET-like  LAN,. SPAWARS  has 
unwittingly  laid  the  foundation  for  Copernicus  communication 
architecture.  This  new  system  has  formed  its  name  as  an 
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analgaiuation  of  the  English  alphah:;»t,  and  vill  be  Icnovn,  at 
least  for  the  interls,  as  MJfTLP  or  the  Modernized  Naval  Front 
End  Processor.  [Ref.  23] 

The  KNFEP  program  is  the  epitome  of  the  Copernicus 
vision,  as  it  will  consolidate  and  substuae  all  of  the  special 
tactical  circuits  that  each  ship  must  monitor  Ci*^*/  OTCIXS, 
TAOIXCS,  JOTS,  FSB,  etc.).  The  circuit  that  is  most  important 
(at  least  to  this  thesis)  is  the  FSB  (Fleet  Satellite 
"message"  Broadcast) .  Currently,  the  FSB  is  transmitted  by 
CUDIXS  on  shore  and  received  by  NAVMACS  at  sea.  Now  MNFEP 
will  perform  all  functions  previously  accomplished  by  NAVMACS 
and  more  [Ref.  23].  The  front  end  of  this  system  will  receive 
from  the  various  pieces  of  communications  equipment  each 
tactical  circuit  which  will,  in  turn,  be  processed  by  two  DTC> 
2  computers.  The  processing  will  direct  each  tactical  circuit 
tcward  its  appropriate  location  via  the  ship's  LAN  (SAFENET  II 
interface).  [Ref.  24] 

Each  circuit  had  previously  required  its  own  system  of 
equipment  to  support  it,  but  now  only  the  software  within  the 
MNFEP  will  define  the  previc'us  system^,  and  NAVMACS  is  no 
different.  Within  MNFEP  will  exist  what  will  be  )cnown  as 
NAVMACS  II  and,  instead  of  having  over  30  pieces  of  NAVMACS 
specific  components,  it  will  share  less  than  15  with  all  the 
other  tactical  circuits.  Of  these  modem  components,  there 
will  be  two  DTC-2  computers,  an  optical  as  well  as  a  magnetic 


49 


disk  storage  device,  two  high-speed  shielded  printers  and  a 
IAN  transceiver  [Ref.  24]. 

The  designing  concept  behind  MNFEP  is  that  software 
Bust  be  modular  and  evolutionary,  in  that,  as  each  new  version 
becomes  available,  it  need  only  be  input  into  the  computer  as 
opposed  to  the  old  way  of  redesigning  the  entire  system.  The 
modularity  ground  rule  also  applies  to  the  system  as  a  whole 
as  designers  must  keep  in  mind  the  lessons  learned  from  the 
old,  rigid  NAVMACS  system  which  was  difficult  to  expand  and 
conform  to  changing  requirements. 

Unfortunately,  MNFEP  and  NAVMACS  II  are  in  their 
infancy,  and  most  information  regarding  specific  capabilities 
is  not  yet  available.  The  one  thing  that  is  apparent, 
however,  is  that  this  program  is  being  pushed  through  the 
acquisition  system,  and  a  prototype  is  being  planned  for  late 
1991,  with  the  first  battle  group  installation  and  Operational 
Test  and  Evaluation  (OPT&E)  to  be  conducted  in  mid-1992  [Ref. 
24]. 

One  of  the  major  pluses  for  this  Copernicus-sponsored 
project  is  the  fact  that  the  main  component  of  the  MNFEP  is 
the  DTC-2  computer  which  is  being  installed  on  every  deploying 
ship  since  the  beginning  of  the  Persian  Gulf  crisis  in  late 
1990.  By  late  1996,  it  is  expected  that  the  entire  fleet  will 
have  an  MNFEP  system  installed.  [Ref.  23] 
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C.  COKCLUSXOK 

Mentione'i  earlier  in  thi3  chapter  was  the  fact  that  there 
is  a  transmission  capacity  problem  that  must  be  overcome 
before  the  X.400-ba£ed  DMS  system  can  be  extended  to  shipboard 
at-rsea  users.  The  problem  remains  as  funding  in  the  area  of 
satellite  transmissions  in  the  range  of  Extremely  High 
Frequency  (EHF)  has  slowed  to  a  trickle.  It  is  felt  that 
recent  events  in  the  Middle  East  have  shown  how  vital  high- 
capacity  transmission  caped^ility  is,  and  that  this  reality 
will  provide  the  impetus  to  the  search  for  a  larger  "pipe**  for 
at-sea  users.  The  onslaught  of  computer  technology  has 
created  tremendous  opportunity  for  the  fleet.  In  vital  areas 
such  as  communications,  where  previous  procedures  have  left  us 
with  much  to  be  desired,  automation  will  soon  be  the  rule  and 
not  the  exception. 
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V.  C0MCLU8I0H:  FDTUSS  SmCTS  O?  OMS  ON  THS  IIAVY 

As  the  DoD,  and  the  Navy  specifically,  xxishes  toward  a 
potential  panacea  of  perfomance  boosting  and  cost  savings 
through  the  embrace  of  message  system  automation  via  the  DMS 
and  BITS  programs,  it  is  important  to  stop  and  reflect  on  what 
the  potential  collateral  effects  might  be. 

A.  SnSVZVABILITT 

Being  edile  to  achieve  high  system  survivability  from 
severe  d2unage,  whether  it  be  caused  by  battle  at  sea  or 
natural  disaster  ashore,  is  a  critical  requirement  for  any 
DoD-wide  communication  system.  For  the  Navy,  the  past  has 
proven  that  the  militarized  Ail/UYK-44  computer  has  performed 
admireUsly  with  an  outstanding  record  for  maintainzUbility.  A 
SPAWAI^  designer  once  quipped  that  a  ship  could  take  a  hit 
from  a  16-inch  round  and  keep  communicating.  But  at  what 
cost? 

In  the  past,  the  pref (erred  Nay  of  designing  communication 
systems  was  to  develop  each  piece  of  equipment  from  the  ground 
up,  component-by-component,  and  build  it  to  meet  militarized 
specifications  to  ensure  high-reliability.  But,  would  that 
prevent  battle  damage  or  provide  protection  from  fire  or 
flooding?  No,  probably  not.  The  next  designing  plan  was  to 
physically  separate  vital  and  redundant  components  (that  were 
highly  militarized,  of  course!)  in  different  compartments 
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which  would  ensure  survlvzdsility  by  the  sheer  numbers  of  back¬ 
ups.  Again,  at  what  cost?  [Ref.  25:pp  226-237] 

A  Navy  example  of  the  service-wide  costs  that  have  been 
incurred  are  manifested  when  the  NAVMACS  program  is  examined. 
The  bottom-line  result  is  a  slow  and  laborious  acquisition 
cycle  that  takes  years  to  field  a  communications  system.  This 
has  resulted  in  a  system  that  is  so  heavily  platform-specific 
in  its  design  that  it  is  neither  transplantaUale  nor  easily 
reconfigured  to  meet  changing  requirements.  The  fact  remains 
that  computer  and  network  technologies  have  become  so 
powerful,  so  reliable,  so  fast,  and  so  inexpensive  that  the 
survivability  considerations  spelled  out  above  are  easily 
achieved  at  relatively  low  costs  and  in  recozd.  time. 

B.  LOOXBTICS  COMSIOBRATIONB 

In  DoO  acquisition  cycles,  one  of  the  potential  downfalls 
for  any  major  program  can  occur  in  the  area  known  as 
Integrated  Logistical  Support  (ILS) .  This  is  euphemistically 
known  as  the  "catch-all"  in  program  management.  ILS  tends  to 
collect  leftover  odds-and-ends,  system  documentation,  training 
guidelines,  manning  requirements  and  spare-parts.  These 
program  elements,  though  vital,  are  normally  considered  to  be 
low  priority  items  until  the  programs  are  about  to  be  fielded. 
Unfortunately,  by  then,  much  of  the  development  money  is  gone 
or  has  been  taken  away. 

The  result  of  this  kind  of  program  management  is  that  the 
system  users  often  receive  equipment  they  have  no  idea  what  to 


do  with.  This  worst-case  situation  is  exemplified  by  the 
recent  flood  of  computing  devices  that  suddenly  arrived  in  the 
fleet  during  the  mid-80s. 

fOien  the  Desk  Top  Tactical  Computer  (DTC-l)  first  hit  the 
fleet,  the  happy  recipients  were  overjoyed  to  get  these  great 
computing  machines.  Trouble  began  later  when  there  were  no 
standard  operating  procedures,  training  programs,  spare  parts 
or  "deck-plate*  level  expertise  to  ease  these  PCs  into  the 
daily  functions  of  the  command.  Many  man-hours  were  wasted  as 
data  files  were  lost  due  to  operator  errors  cr  system  crashes. 
The  only  plausible  answer  for  this  disaster  is  that  the  Navy 
was  not  prepared  to  purchase  these  systems  and  install  them  in 
the  fleet  in  such  a  short  period  of  time. 

Now,  standard  operating  procedures  have  been  established, 
training  is  avail2d>le  and,  most  importantly,  security 
requirements  are  being  addressed  at  all  levels  throughout  the 
Navy.  The  question  now  is  *ls  it  enough?*  as  the  DoD  embarks 
on  a  wholesale  automation  of  systems  that  was  previously 
performed  at  such  rudimentary  levels  as  pen-and-ink  message 
drafting. 

1.  Manning 

In  mid-1990.  Vice  Admiral  J.O.  Tuttle,  Director,  Space 
and  Electronic  Warfare,  the  CNO's  man  in  charge  of  all  naval 
C^  development,  directed  that  the  first  of  many 
interdisciplinary  mergers  would  take  place  between  the  Naval 
Data  Automation  Command  (NAVDAC)  and  the  Naval 
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Telecoonunications  Comnand  (NAVTELCOMM) .  This  new  entity  is 
now  known  as  the  Naval  Coaputers  and  Teleconmtmications 
Conmand  (NCTC)  and  was  established  to  ensure  that  required 
modernization  in  Naval  telecommunications  was 
institutionalized  from  the  top  to  the  bottom.  If  the  cost 
savings  conceived  by  OMS  and  BITS  plzuiners  were  to  be 
realized,  not  only  did  the  Navy  have  to  update  its  equipment 
but  also  its  personnel.  NCTC,  by  its  position  at  the  top  of 
both  the  Naval  communications  and  computers  disciplines,  was 
the  perfect  position  to  organize  this  transformation.  Since 
that  first  merger,  several  lower  level  commands  have  followed 
suit,  which  has  resulted  in  a  little  confusion  as  well  as 
tremendous  Naval  commxinicaticns  opportunities.  [Ref.  26:p.  2] 
The  implications  of  the  NCTC  merger  were  felt 
throughout  the  Navy,  from  Washington,  DC  to  the  Naval 
Postgraduate  School  in  Monterey,  California.  This  merging 
policy  decision  turned  out  to  be  a  logistical  support  program 
of  massive  proportions  as  service  school  training  commands 
gear>up  to  Cross-train  Radioman  (RM)  as  Data  Processing 
Technicians  (DP)  and  vice  versa.  On  the  other  end  of  the 
personnel  spectrum,  two  officers'  education  programs  blended 
into  the  new  sub-specialty  defined  as  Information  Systems 
Specialist,  which  was  bom  from  the  previous 
Telecommunications  and  Computer  Systems  Management  fields. 
[Ref.  26:pp.  58-60  and  82] 
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Navy's  path  toward  a  complete  merger  of  computers  and 
communication  has  just  begun  and  there  remain  many  questions 
to  be  answered.  Of  the  most  significant  impediments  to  a 
complete  functional  merger  is  the  fact  that  there  are  vanning 
degrees  of  professional  pride  and  colloquial  prejudices  within 
each  group,  which  could  create  resistance  to  this  mandated 
change.  Adding  to  the  confusion  is  the  fact  that  not  all  of 
the  Navy  will  require  these  interdisciplinary  skills  right 
away.  The  reality  of  the  situation  is  that  ships  at  sea  will 
continue  to  need  different  telecommiuiicatioh  skills  than  will 
the  communicators  ashore,  and  as  long  as  sailors  rotate  from 
ship-to-shore  periodically,  their  functional  skill  base  must 
continue  to  remain  very  broad. 

2 •  Training 

To  bridge  the  gap  among  formal  service  school 
training,  sub-specialty  graduate  education  and  the  rest  of  the 
fleet,  a  Navy-wide  computer  training  and  awareness  program 
must  be  instituted.  The  underpinnings  of  any  successful 
change  is  acceptance,  and  that  can  be  fostered  when  the  stigma 
of  computerized  "black  magic"  and  "mystery"  is  dispelled  by 
bottom-to-top  training. 

Formal  training  is  required  for  all  computer  users  as 
dictated  by  Navy  regulation.  As  more  and  more  people  become 
aware  of  their  usefulness,  compiuters  will  become  commonplace 
in  the  Navy.  The  kinds  of  professional  training  that  will  be 
required  transcends  anything  that  has  gone  before  it,  as  the 
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Navy  Cand  the  DoD)  is  now  attempting  not  only  to  march  to  the 
forefront  of  telecommunications  technology  but  also  to 
actually  lead  it. 

The  skills  required  to  meet  future  technical  needs 
will  take  a  considerable  amount  of  sophisticated  training,  and 
to  be  truly  effective,  will  require  a  cadre  of  intelligent 
individuals  to  form  a  foundation.  Until  then;  those  that  are 
receiving  the  initial  professional  training  must  guard  against 
the  pitfalls  of  computer  ignorance  emd  misuse,  as  novice 
computer  users  "hack"  their  way  through  operating  systems  and 
data  files,  destroying  hard  work  and  equipment  along  the  way. 

C.  SBCURITY 

Security  awareness  is  the  thread  that  binds  manning  and 
training  requirements  with  respect  to  ILS  programs.  As 
computer  usage  continues  to  increase,  it  will  become  an 
unstoppable  part  of  DMS  subscriber's  lives.  In  the  future 
both  physical  and  informational  security  wi^  become  all  that 
more  Important.  As  aiscussed  earlier  in  this  thesis the  OoO 
is  spelling  out  exactly  what  is  expected  from  industry  in 
terms  of  built-in  or  trusted  computer  security  systems. 
Unforttuiately,  these  types  of  hardware  and  software  security 
restraints  are  in  their  infancy  and  both  BITS  and  the  DMS  are 
heavily  dependent  on  the  rapid  maturity.  As  a  result  of  the 
lack  of  transparent  or  involuntary  security  restrictions,  we 
must  rely  on  self-imposed  protection  to  prevent  the 
possibility  of  accidental  or  planned  Insecurities.  This  level 


f 


of  security  can  be  accomplished  by  the  linking  of  properly 
skilled,  ed>le-bodied  personnel  and  relentless  vigilance. 

D.  LOOSE  BHDS 

In  conclusion,  it  is  obvious  that  there  is  a  lot  of  work 
ediead  for  everyone,  from  the  OMS  planners,  attempting  to 
maintain  funding  levels  and  a  unity  of  vision  among  services, 
to  Naval  Radioman  personnel,  who  will  be  seeing  not  only  their 
rating  overhauled  but  also  must  face  the  brunt  of  the  momentum 
that  has  built  up  behind  the  demand  for  automation  in  the 
Navy. 

This  evolutionary  telecommunication  process  has  quickly 
become  time  critical,  and  any  slowdown  by  the  key  programs 
(i.e.,  pMS  backbone,  BITS  pier*-side  interface,  an  effective 
ship-shore  transmission  capability,  etc.)  will  result  in 
considerable  costs  to  the  system  as  a  whole.  This  slowdown 
will  require  redundant  communications  systems  that  are  capable 
of  providing  services  at  both  levels  of  technology,  old  and 
new. 

Protocol  changeovers  such  as  X.400,  ISDN  and  GOSIP  will 
require  increased  capabilities  in  computing  sophistication, 
critical  technology  maturity  and  transmission  bandwidth  usage. 
These  key  areas  will  be  the  deciding  factor  as  to  whether  "The 
Impact  of  the  Defense  Message  System  on  the  United  States 
Surface  Navy"  is  a  mere  bump  in  the  night  or  a  collision  at 
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